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f^*) . Abstract 

We define a proof system for exceptions which is close to the syntax for exceptions, in the sense that 
the exceptions do not appear explicitly in the type of any expression. This proof system is sound with 
respect to the intended denotational semantics of exceptions. With this inference system we prove several 
properties of exceptions. Keywords. Computational effects. Semantics of exceptions. Proof system. 



Introduction 



In this paper, as in the apparented papers [TJ [4j [3], we consider that a computational effect in a language 
corresponds to an apparent lack of soundness: the intended denotational semantics is not a model of the 
(yl , syntax, but it becomes so when the syntax is endowed with relevant decorations] more precisely, a proof 

system can be designed for dealing with these decorations, which is sound with respect to the intended 
denotational semantics. In [3] this point of view has been applied to the side-effects due to the evolution of 
the states of the memory in an imperative or object-oriented language. In this paper, it is applied to the 
effects caused by exceptions. It happens that there is a duality between the denotational semantics of states 
and the core part of the semantics of exceptions [2] . The encapsulation of the core part inside the mechanism 
of exceptions is a succession of case distinctions; the proof system is extended for dealing with it. Properties 
of exceptions can be proved using this inference system and the proofs can be simplified by re-using proofs 
on states, thanks to the duality. 

To our knowledge, the first categorical treatment of computational effects is due to Moggi [11]; this 
approach relies on monads, it is implemented in the programming language Haskell [16, 8 . Although monads 
are not used in this paper, the basic ideas underlying our approach rely on Moggi's remarks about notions 
of computations and monads. The examples proposed by Moggi include the exceptions monad TA = A + E 
where E is the set of exceptions. Later on, using the correspondence between monads and algebraic theories, 
Plotkin and Power proposed to use Lawvere theories for dealing with the operations and equations related 
to computational effects |12| [9] ; an operation is called algebraic when it satisfies some relevant genericity 
properties. The operation for raising exceptions is algebraic, while the operation for handling exceptions is 
not [13] ■ It follows that the handling of exceptions is quite difficult to formalize in this framework; several 
solutions are proposed in [151 1101 I14j . In this paper we rather use the categorical approach of diagrammatic 
logics, as introduced in 5 and developed in pQ. 

In Section Q] a denotational semantics for exceptions is defined, where we dissociate the core operations 
from their encapsulation. Then a decorated proof system and a decorated specification for exceptions are 
defined in Section [5] and it is checked that the denotational semantics for exceptions can be seen as a model 
of this specification. In Section [3] we use this framework for proving some properties of exceptions. 
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1 Denotational semantics for exceptions 

In this Section we define a denotational semantics of exceptions which relies on the semantics of exceptions in 
various languages, for instance in Java [B] and ML 7 . Syntax is introduced in Section [TTT] and the distinction 
between ordinary and exceptional values is discussed in Section 11.21 Denotational semantics of raising and 
handling exceptions are considered in Sections 11.31 and 11.41 respectively. 

1.1 Signature for exceptions 

The syntax for exceptions in computer languages depends on the language: the keywords for raising excep- 
tions may be either raise or throw, and for handling exceptions they may be either handle or try-catch, 
for instance. In this paper we rather use throw and try-catch, but this choice does not matter. More 
precisely, the syntax of our language may be described in two parts: a pure part and an exceptional part. 
The pure part is a signature Sig , made of types and operations; the Sig e -expressions are called the 
pure expressions. The interpretation of the pure expressions should neither raise nor handle exceptions. We 
assume that the pure operations are either constants or unary. General n-ary operations would require the 
use of sequential products, as in 4 ; in order to focus on the fundamental properties of exceptions they are 
not considered in this paper. The exceptional part is made of a symbol Ei for each index i in some set of 
indices /, which is declared as: Exception Ei of Pi, where Pi is a pure type called the type of parameters for 
the exceptional type Ei (the Pi's need not be distinct). The exceptional types Ei provide familiar notations 
for the raising and handling operations and in Section [1.31 they are interpreted as sets, however we will not 
define any expression of type Ei . 

Let us assume that the signature Sig pure is fixed. The expressions of our language are defined recursively 
from the pure operations and from the raising and handling operations, as follows. 

Definition 1.1. Given a set of indices / and a symbol Ei for each i £ I, the signature for exceptions Sig oxc 
is made of Sig puro together with a raising operation for each i in I and each type Y in Sig puro : 

throwy Ei : Pj -)■ y . 

and a handling operation for each Sig oxc -expression / : X — > Y, each non-empty list of indices (ii,... ,i n ) 
and each Sig cxc -expressions g\ : Pi ± —}Y, . . . , g n : Pi n — > Y: 

try{f) catch {E n =>g x \ . . . \E in =>g n } : X ->• Y . 

1.2 Ordinary values and exceptional values 

The syntax for exceptions defined in Section 11.11 is now interpreted in the category of sets. In order to 
express the denotational semantics of exceptions, a major point is that there are two kinds of values: the 
ordinary (or non-exceptional) values and the exceptions. It follows that the operations may be classified 
according to the way they may, or may not, interchange these two kinds of values: an ordinary value may 
be tagged for constructing an exception, and later on the tag may be cleared in order to recover the value. 
Then we say that the exception gets untagged. Let us introduce a set Exc called the set of exceptions. 
For each set X we consider the disjoint union X + Exc with the inclusions normalx '■ X — > X + Exc and 
abrupt x : Exc — > X + Exc. 

Definition 1.2. For each set X, an element of X + Exc is an ordinary value if it is in normalx(X) and an 
exceptional value if it is in abrupt x (Exc) . A function f : X + Exc — >• Y + Exc is said to raise an exception 
if there is an element x £ X such that f(x) £ Exc; propagate exceptions if f (abrupt x (e)) — abrupt Y (e) for 
every e 6 Exc; recover from an exception if there is some e S Exc such that /(e) G Y. 

We will use the same notations for the syntax and for its interpretation. Each type X is interpreted as a 
set X. Each pure expression /o : X — > Y is interpreted as a function /o : X — >■ Y, which can be extended as 
/ = normaly ° fa '■ X — > Y + Exc. When / : X — > Y is a Sig cxc -expression, which may involve some raising or 



handling operation, its interpretation is a function / : X — > Y + Exc which is defined in the next Sections II. 31 
and 1 1.41 In addition, every function /:X->7 + Exc can be extended as [/ | abrupt Y ] ■ X + Exc — > Y + Exc, 
which is defined by the equalities [/ 1 abrupt Y ] ° normal x = f and [/ 1 abrupt Y ] ° abrupt x = abrupty. This 
is the unique extension of / to X + Exc which propagates exceptions. 

Remark 1.3. The interpretation of a Sig cxc - expression f : X — >• Y is a function which propagates exceptions; 
this function may raise exceptions but it cannot recover from an exception. In Section [1.41 in order to catch 
exceptions, we will introduce functions which recover from exceptions. However such a function cannot 
be the interpretation of any Sig oxc -expression. Indeed, a try-catch expression may recover from exceptions 
which are raised inside the try block, but if an exception is raised before the try-catch expression is evaluated, 
this exception is propagated. Recovering from an exception can only be done by functions which are not 
expressible in the language generated by Sig cxc : such functions are called the untagging functions, they are 
defined in Section 11.41 Together with the tagging functions defined in Section 11.31 they are called the core 
functions for exceptions. 

1.3 Tagging and raising exceptions: throw 

Raising an exception is based on a tagging process, modelled as follows. 

Definition 1.4. For each index i £ I there is an injective function t% : P% — > Exc, called the exception 
constructor or the tagging function of index i, and the tagging functions for distinct indices have disjoint 
images. The image of U in Exc is denoted Ei. 

Thus, the tagging function ti : Pi — > Exc maps a non-exceptional value (or parameter) a £ Pi to an 
exception U(a) £ Exc. This means that the non-exceptional value a in Pj gets tagged as an exception U(a) 
in Exc. The disjoint union of the E%'s is a subset of Exc; for simplicity we assume that Exc = J2i£i Ei ■ 

Definition 1.5. For each index i £ I and each set Y, the throwing or raising function throw y Ei is the 
tagging function ti followed by the inclusion of Exc in Y + Exc: throwy Ei = abrupty ° U : Pi — > Y + Exc . 

1.4 Untagging and handling exceptions: try-catch 

Handling an exception is based on an untagging process for clearing the exception tags, which is modelled 
as follows. 

Definition 1.6. For each index i £ I there is a function c, : Exc — > Pi + Exc, called the exception 
recovery or the untagging function of index i, which satisfies: Va £ Pi Cj(tj(a)) = a and V6 £ Pj Ci(tj(b)) = 
tj (6) for each j ^ i . 

Thus, for each e £ Exc the untagging function Cj(e) tests whether the given exception e is in Ei; if this is 
the case, then it returns the parameter a £ Pi such that e = U(a), otherwise it propagates the exception e. 
Since it has been assumed that Exc = $^.- e j Ej, the untagging function Cj(e) is uniquely determined by the 
above equalities. 

For handling exceptions of type Ei raised by some function / : X — > Y + Exc, for i in a non-empty list 
(ii, . . . , i n ) of indices, one provides for each k in {1, . . . , n} a function g^ : Pi h — > Y + Exc (which thus may 
itself raise exceptions). Then the handling process builds a function which encapsulates some untagging 
functions and which propagates exceptions. The indices i\, . . . , i n form a list: they are given in this order 
and they need not be pairwise distinct. It is assumed that this list is non-empty, because it is the usual 
choice in programming languages, however it would be easy to drop this assumption. 

Definition 1.7. For each function / : X — > Y + Exc, each non-empty list (i\, . . . ,i n ) of indices in / and 
each family of functions gk '■ Pi k — > Y + Exc (for k £ {1, . . . , n}), the handling function 

try{f} catch {E h =>gi\. . . \E in ^g n } : X -)• Y + Exc 

is defined as follows. Let h = try{f} catch {E^ =4> gi\ . . . |JSj n =>■ g n }, for short. For each x £ X, h(x) £ 
Y + Exc is defined in the following way. 



First f(x) is computed: 
let y = f(x) e Y + Exc. 

(1) If y is not an exception, then it is the required result: 
if y e Y then h(x) = y G Y C Y + Exc. 

(2) If y is an exception, then: 

(a) If the type of y is Ei for some index i in (i\, . . . , i n ), then y has to be cauyht according to the 
first occurrence of the index i in the list: 

for each k = 1, . . . , n, 

— Check whether the exception y has type Ei k : 
let z = c ik (y) 6 P{ k + Exc. 

— If the exception y has type Ei k then it is caught: 
if z G Pi k then h(x) = gu{z) <EY + Exc. 

(b) If the type of y is Ei for some i g" {ii, . . . ,i n }, then y is propagated: 
otherwise h(x) = y G Exc C7I Exc. 

Equivalcntly, the definition of h — try{f} catch {Ei t =><?i| . . . \Ei n ^g n } can be expressed as follows. 

(1-2) The function h : X — > Y + Exc is defined from / and from a function catch {Ei t =4-<7i| . . . \Ei n =?g n } '■ 
Exc — >• Y + Exc by: 



h 



normaly \ catch {Ei t =>gi\. . . \Ei n =><? n } 



of 



(1) 




Y + Exc 



h{E zl ^g 1 \...\E in ^g„} 



(a-b) The function catch {E^ =>■ gi\ . . . \Ei n => g n } is obtained by setting p — 1 in the family of 
functions k p — catch {Ei =4> g p \ . . . \Ei n =>■ g n } '■ Exc — > Y + Exc (for p = 1, . . . ,n) which are 
defined recursively by: 



{[ g n | abrupty 1 o Ci n when p = n 
[ g p | fcp+i ] o c ip when p < n 

Let /c n +i = abrupty, then fc p = [ g p \ k p+ \ } o Ci p for each p < n. 



(2) 



Eic 




abruptT 

Exc 



Y + Exc 



When n = 1 we get £n/{/} caic/i {i?i => 5} = normaly \ \g\abrupty\ o c, o / . 

Remark 1.8. The handling process involves several nested case distinctions. Since it propagates exceptions, 
there is a first case distinction for checking whether the argument x is an exception (which is simply prop- 
agated) or not. If x is not an exception, then there is a case distinction (1-2) for checking whether f(x) is 
an exception or not. If f{x) is an exception then each step (a-b) checks whether the result of the untagging 
function is an exception. All these case distinctions check whether some value is an exception or not, they 
rely on disjoint unions of the form T + Exc. In contrast, for each step (a-b) there is another case distinction 
encapsulated in the computation of the untagging function, which checks whether the exception has the 
required exception type and relies on the disjoint union Exc — ^- Ei. 



2 Decorated logic for exceptions 

In Section[T]we have introduced a signature Sig GXC and a denotational semantics for exceptions. However the 
soundness property is not satisfied: the denotational semantics is not a model of the signature, in the usual 
sense, since an expression / : X — ► Y is interpreted as a function / : X — >• Y + Exc instead of / : X — > Y. 
Therefore, in this Section we build a decorated specification for exceptions, including a "decorated" signature 
and "decorated" equations, which is sound with respect to the denotational semantics of Section [T] For this 
purpose, first we form an equational specification by extending the signature Sig exc with operations U and 
Ci and equations involving them, in order to formalize the tagging and untagging functions of Sections 11.31 
and 11.41 Then we add decorations to this specification, and we define the interpretation of the expressions 
and equations according to their decorations. This means that we have to extend the equational logic 
with a notion of decoration; the decorations and the decorated inference rules are given in Section 12.11 
In Section 12.21 we define the decorated specification for exceptions and in Section 12.31 we check that this 
decorated specification is sound with respect to the denotational semantics of Section [1] In the decorated 
specification for exceptions, there are on one side private operations for tagging and untagging exceptions, 
which do not appear in the signature for exceptions Sig cxc , and on the other side public operations for 
raising and handling exceptions, which arc defined using the private operations. According to remark [1.31 
an important feature of exceptions is that all public operations propagate exceptions, such operations will be 
called propagators] operations for recovering from exceptions may appear only as private operations, which 
will be called catchers. 

2.1 Decorations 

In order to deal with exceptions we define three decorations for expressions. They are denoted by (0), (1) 
and (2) used as superscripts, and their meaning is described in an informal way as follows. 

• The interpretation of a pure expression /(°) may neither raise exceptions nor recover form exceptions. 

• The interpretation of a propagator f( l > may raise exceptions but it is not allowed to recover from 
exceptions; thus, it must propagate all exceptions. 

• The interpretation of a catcher f^ 2 ' may raise exceptions and recover form exceptions. 

Every pure expression can be seen as a propagator and every propagator as a catcher. It follows that every 
expression can be seen as a catcher, so that the decoration (2) could be avoided; however we often use it for 
clarity. 

In addition, we define two decorations for equations. They are denoted by two distinct relational symbols 
= for strong equations and by ~ for weak equations. Using the fact that every expression can be seen as a 
catcher, their meaning can be described as follows. 

• A strong equation /' 2 ' = g^ 2 > is interpreted as an equality of the functions / and g both on ordinary 
and on exceptional values. 

• A weak equation f 1 - 2 ' ~ g( 2 > is interpreted as an equality of the functions / and g on ordinary values, 
but / and g may differ on exceptional values. 

Clearly every strong equation f = g gives rise to the weak equation / ~ g. On the other hand, since 
propagators cannot modifiy the exceptional values, every weak equation between propagators can be seen 
as a strong equation, and a similar remark holds for pure expressions. 

Remark 2.1. It follows from these descriptions that every catcher k gives rise to a propagator Vk with a 
weak equation k ~ Vk: this propagator Vfc has the same interpretation as k on the non-exceptional values 
and it is interpreted as the identity on the exceptional values. 



In the short note [5] it is checked that, from a denotational point of view, the functions for tagging 
and untagging exceptions are respectively dual, in the categorical sense, to the functions for looking up and 
updating states. It happens that this duality also holds from the decorated point of view. Thus, most of 
the decorated rules for exceptions are dual to the decorated rules for states |3]- The decorated rules for 
exceptions are given here in three parts (Figures [TJ [5] and [3]) . For readability, the decoration properties are 



often grouped with other properties: for instance, "/ 
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means "fv-) and g^ and / ~ g" . 



The rules in Figure [T] may be called the rules for the decorated monadic equational logic for exceptions. 
The unique difference between these rules and the dual rules for states lies in the congruence rules for 
the weak equations: for states the replacement rule is restricted to pure g's, while for exceptions it is the 
substitution rule which is restricted to pure /'s. 
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Figure 1: Decorated rules for exceptions (1) 

Several kinds of decorated coproducts are used for dealing with exceptions. The rules in Figure [5] are the 
rules for a decorated initial type 0, also called an empty type, and for a constitutive coproduct, as defined 
below. These rules are dual to the rules for the decorated final type and for the observational product for 
states in [3]. 

Definition 2.2. A decorated initial type for exceptions is a type such that for every type X there is a 
pure expression [] x : — > X such that every function from to X is weakly equivalent to [] x . 

It follows that every pure expression and every propagator from to X is strongly equivalent to [] x . 

Definition 2.3. A constitutive coproduct for exceptions is a family of propagators {qt : Xi — > X)i such that 
for every family of propagators (/, : X, — 5- Y)i there is a catcher / = [f^ : X — > Y, unique up to strong 
equations, such that / o q i ~ /^ for each i. 

This definition means that a constitutive coproduct can be used for building a catcher from several 
propagators; this corresponds to the fact that the set Exc is the disjoint union of the E^s. 
The next property corresponds to remark \2. II 

Definition 2.4. For each catcher k^ : X — > Y there is a propagator VfcW : X — > Y, unique up to strong 
equations, such that V/c^ ~ k^ . 
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Figure 2: Decorated rules for exceptions (2) 



According to the previous rules, for each type X there are two pure expressions zdx : X — > X and 
[} x : — >• X. It is straightforward to check that they form a coproduct with respect to pure expressions 
and strong equations: for each f(°> : X — » Y and g^ : © — > Y there is a pure expression [f\g] ■ X — > Y, 
unique up to strong equations, such that [f\g] ° idx = / and [f\g] ° [] x = .<?, indeed such a situation implies 
that g = [] x and [f\g] = f. This pure coproduct, with coprojections id x and [] x , is called t/ie coproduct 
X = X + 0. In addition, we assume that it satisfies the following decorated coproduct property. 

Definition 2.5. For each propagator g^ : X — > Y and each catcher k^ : — > Y there is a catcher 
[g | £;] : X — > Y, unique up to strong equations, such that [5 | fc] ~ g^ and [g \ ky- o [] x ' = fc( 2 ) . 

The rules in Figure [3] are the rules for the construction of V/c and for the decorated coproduct X = X + ©. 
They will be used for building the handling operations from the untagging operations. 
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Figure 3: Decorated rules for exceptions (3) 



2.2 A decorated specification for exceptions 

Let C denote the inference system provided by the decorated rules for exceptions (Figures [TJ [2] and [3]) . As for 
other inference systems, we may define theories and specifications (or presentations of theories) with respect 
to C They are called decorated specifications and decorated theories, respectively. This approach is based on 
the general framework for diagrammatic theories and specifications [5j[l], but no knowledge of this framework 
is assumed in this paper. A decorated theory is made of types, expressions, equations and coproducts which 
satisfy the decorated rules for exceptions. In this Section we define a decorated specification S cxc , which 
may be used for generating a decorated theory by applying the decorated inference rules for exceptions. 



Definition 2.6. Let £ purc be some fixed equational specification (as in Section fOl for simplicity it is assumed 
that S puro has no n-ary operation with n > 1). The decorated specification for exceptions S oxc is made of 
the equational specification £ purc where each operation is decorated as pure and each equation as strong 
(or weak, since both coincide here), a type called the empty type and for each i in some set / a type 



Pi (of parameters) in E pure , a propagator t\ . Pi 



a catcher c 



(2) 



Pi and the weak equations: 



d o ti ~ id : Pi — > P, and & o £,- 



[] o tj : Pj ->■ Pi for every j e I, j ^ i. 



Definition 2.7. For each i in / and each type Y in S pure the raising propagator 

{throw Y E, t ) {1) :Pi^Y 

is defined as 

throwy Ei = [] Y o ti : Pi — > Y . 

According to remark [1.31 the handling operation try{f} catch{. . . } is a propagator, not a catcher: indeed, 
it may recover from exceptions which are raised by /, but it must propagate exceptions which are raised 
before try{f} catch{. . . } is called. 

Definition 2.8. For each propagator /W : X — » Y, each non-empty list of indices (ii,... , i n ) and each 

r 
propagators g\ 



(i) 



p tl -> v, 



..,gn : Pi n — > Y, the handling propagator 
{try{f} catch {E n => 9l \ ... \E in ^.g„}) (1) : X 



Y 



is defined as follows. 



(A-B) The propagator try{f} catch {E^ =>gi\ ... \Ei n - 
by: 

{try{f} catch {E n ^ gi \ . . . \E h 



(1-2) The catcher H : X 



fci = catch {E h =$*gi\ . . . \E in =>g n } : 



Y is defined from the propagator / : X 
>Yby. 



;} : X — > Y is defined from a catcher H : X — > Y 

g n })W = (Vtf) (1) : X -> Y 

Y and from a catcher 



/(0) I 1.(2) 



(2) 



o/W :X^F 




(a-b) The catcher hi : 
cafc/i {Pi p =^ p | . . . | Pi, 



Y is obtained by setting p = 1 in the family of catchers fc p 
•t/n} : — > y (for p = 1, . . . , n) which are defined recursively by: 

[fifp | kp+i] o c ip for each p=l,...,n and fc„ + i = [] y 




It will be proved in Lemma l3.2l that since k n +i = []y we have [g n |fc„+i] = g n . It follows that when n = 1 
and 2 we get respectively: 



in/{/} catc/i {P 4 => g} = y ( [* rf v | 9 ° c»] o / ) 
try{f} catch {Ei =^g \ Ej=i>h} = y ( [id | [g | /i o a,] oc,] o / ) 



(3) 

(4) 



2.3 Decorated models 

Let Exc be a set and Pi (for i 6 /) a family of sets with injections ij : P^ — > Exc, such that Exc is the 
disjoint union of the images Ei — ij(Pj). Then we may define a decorated theory O oxc as follows. A type is 
a set, a pure expression f(°> : X — >• Y is a function / : X — > Y, a propagator f^> : X — >• Y is a function 
/ : X — > y + Pic and a catcher /( 2 ) : X — > Y is a function / : X + Pic — >• F + Pre. For instance, each 
injection ti : Pi —} Exc is a propagator t^ : P, — > 0. The conversion from pure expressions to propagators is 
the construction of f\ — normaly ° /o '■ A — > Y + Exc from f : X — > Y and the conversion from propagators 
to catchers is the construction of f 2 — [/ 1 abrupt Y ] ■ X + Exc — > Y + Exc from /j : X — > Y + Exc. 
Composition of two expressions can be defined by converting them to catchers and using the composition of 
functions / : X + Exc — > Y + Exc and g : Y + Exc — >• Z + Exc as g o / : X + Exc — > Z + Exc. When restricted 
to propagators this is compatible with the Kleisli composition with respect to the monad X + Exc. When 
restricted to pure expressions this is compatible with the composition of functions /n : X — s> Y and go : Y — > Z 
as go o fo ■ A — > Z. A strong equation f^ = g^ : X — > Y is an equality (Vx <E X + Exc, f(x) — g(x)), and 
a weak equation / ~ g : X — > Y is an equality (Vie G X, f(x) — g(x)); when restricted to propagators both 
notions coincide. The empty set is a decorated initial type and the family of propagators (t\ : Pi — > 0) is 
a constitutive coproduct, because the family of functions (ti '■ Pi — > Exc) is a coproduct in the category of 
sets. 

The models of a decorated specification E with values in a decorated theory are defined as kinds of 
morphisms from E to in [II: a model maps each feature (type, pure expression, propagator, catcher, 
decorated initial type, constitutive coproduct, . . . ) of E to a feature of the same kind in 0. When is the 
theory OXC we recover the meaning of decorations as given informally in Section 12.11 When in addition E 
is the specification E oxc we get the following result. 

Theorem 2.9. The decorated specification for exceptions E cxc is sound with respect to the denotational 
semantics of Section^ in the sense that by mapping every feature in E exc to the feature with the same name 
in the decorated theory CXC we get a model of E cxc with values in OXC . 

Proof. For the tagging and untagging operations this is clear from the notations. Then for the raising 
operations the result is obvious. For the handling operations the result comes from a comparison of the steps 
(1-2) and (a-b) in Definitions 12.81 and 1 1 . 71 while step (A-B) in Definition 12.81 corresponds to the propagation 
of exceptions by the handling functions, as in remark [FBI □ 

3 Proofs involving exceptions 

As for proofs on states in [3], we may consider two kinds of proofs on exceptions: the explicit proofs involve 
a type of exceptions, while the decorated proofs do not mention any type of exceptions but require the 
specification to be decorated, in the sense of Section [51 In addition, there is a simple procedure for deriving 
an explicit proof from a decorated one. In this Section we give some decorated proofs for exceptions, using 
the inference rules of Section [2. II Since the properties of the core tagging and untagging operations are dual 
to the properties of the looking up and updating operations we may reuse the decorated proofs involving 
states from [3] . Starting from any one of the seven equations for states in |12j we can dualize this equation 
and derive a property about raising and handling exceptions. This is done in this Section for two of these 
equations. 

On states, the annihilation lookup-update property means that updating any location with the content 
of this location does not modify the state. A decorated proof of this property is given in [3J . By duality we 
get the following annihilation untag-tag property, which means that tagging just after untagging, both with 
respect to the same exceptional type, returns the given exception. 

Lemma 3.1 (Annihilation untag-tag). For each i 6 I: t\ o c\ I = id® . 

Lemma 13.11 is used in Proposition 13.31 for proving the annihilation catch-raise property: catching an 
exception by re-raising it is like doing nothing. First, let us prove Lemma 13.21 which has been used for 
getting Equation ([3]). 



Lemma 3.2. For each propagator g** 1 ' : X —> Y we have [g | [] Y ] — 9 ■ 

Proof. Since [g\ [] Y ] is characterized up to strong equations by [g\ [] Y ] ~ g and [g\ [] Y ] o[] x = [} Y , we have to 
prove that g ~ g and go [] x = [] Y . The weak equation is due to the renexivity of ~. The unicity of [] Y up to 
weak equations implies that jo[]^ ~ [] Y , and since both members are propagators we get 9°[]v = []y d 

Proposition 3.3 (Annihilation catch-raise). For each propagator f^ : X — > Y and each i 6 I: 
try{f} catch {Ei => throwy -£■»} = /• 

Proof. By Equation ([3]) and Definition 12.71 we have try{f} catch {Ei => throwy Ei} = v([idy | [] y ot,o q] o 
/). By Lemma 13.11 [idy\ [] Y ° U o q] = [idy| []y], and the unicity property of [id Y \ [] Y ] implies that 
[idy\ [] Y ] = idy. Thus try{f} catch {Ei =>• throw Y Ei} = V/. Finally, since V/ ~ / and / is a propa- 
gator we get V/ = /. □ 

On states, the commutation update-update property means that updating two different locations can be 
done in any order. By duality we get the following commutation untag-untag property, which means that 
untagging with respect to two distinct exceptional types can be done in any order. A detailed decorated 
proof of the commutation update- update property is given in [3J. The statement of this property and its 
proof use semi-pure products, which were introduced in [4] in order to provide a decorated alternative to 
the strength of a monad. Dually, the commutation untag-untag property use semi-pure coproducts, which 
generalize the decorated coproducts X = X + from Definition 12.51 The coproduct of two types A and B 



is defined as a type A + B with two pure coprojections q{ : A — >• A + B and q^ '■ B — > A + B, which 
satisfy the usual categorical coproduct property with respect to the pure morphisms. Then the semi-pure 
coproduct of a propagator /W : A — >• C and a catcher k^ : B — ► C is a catcher [/|fc] : A + -B — >• C 
which is characterized, up to strong equations, by the following decorated version of the coproduct property: 
[f\k] o q 1 ~ / and [f\k]oq 2 = k. Then as usual, the coproduct f' + k' : A + B ^ C + D of a propagator 
f':A-*C and a catcher k' : B ^ D is the catcher /' + fc' = [q-y o f | q 2 o ft] : A + _B -> C + D. Whenever 
<7 is a propagator it can be proved that V [f\g] = [f\g]] thus, up to strong equation, we can assume that in 
this case [/ | g] : A + B — > C is a propagator; it is characterized, up to strong equations, by [/ | g] o q x = / 
and [/ | g] o q 2 = g. 

Lemma 3.4 (Commutation untag-untag). For each i,j G / with i ^ j : 

(d + id Pj ) {2] o cf = (id Pi + e,) (2) o c^ ] : ->■ Pi + Pj 

Proposition 3.5 (Commutation catch-catch). For each i,j€l with i^j: 

try{f} catch{Ei^>g | Ej=$>h} = try{f} catch{Ej=$h \ Ei^>g} 

Proof. According to Equation Q: try{f} catch {E. L =$• g \ E 3 => h} = W([id \ [g \ ho Cj] o Cj] o /) Thus, the 
result will follow from [g \ h o Cj] oq = [h | g o a] ocj. It is easy to check that [g \ h o Cj] = [g \ h] o {idp i +Cj), 
so that [g \ h o Cj] o a = [g \ h] o (jdp 4 + Cj) o Cj . Similarly [/i | g o a] o Cj = [/i | 5] o (idp j + a) o Cj hence 
[/i j ,g o a] o Cj = [g \ h] o (a + id p.) o Cj . Then the result follows from Lemma \'3. 41 □ 
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